セルフマネージドActive Directoryと信頼関係にあるAWS Managed Microsoft ADのユーザーを使ってAmazon FSx for NetApp ONTAPにSMBで接続してみた

セルフマネージドActive Directoryと信頼関係にあるAWS Managed Microsoft ADのユーザーを使ってAmazon FSx for NetApp ONTAPにSMBで接続してみた

信頼関係を組んで適切な権限を付与しよう
Clock Icon2024.06.18

異なるドメインに参加しているファイルサーバーにアクセスしたいな

こんにちは、のんピ(@non____97)です。

皆さんは異なるドメインに参加しているファイルサーバーにアクセスしたいなと思ったことはありますか? 私はあります。

特に起こりうるシチェーションとしてはAmazon Workspaces(以降Workspaces)を使用している場合です。WorkspacesはManaged Microsoft AD(Managed MSAD)に参加させ、ファイルサーバーはオンプレミスやVPC上にあるセルフマネージドADに属しているという場面はよくあるかと思います。

異なるドメインに参加しているファイルサーバーにアクセスする場合は、ドメイン間で信頼関係を組んであげる必要があります。信頼関係の仕組みは以下Microsoft公式ドキュメントをご覧ください。

https://learn.microsoft.com/ja-jp/entra/identity/domain-services/concepts-forest-trust

また、その場合どのようにしてグループアカウントの運用を行い、どのようにしてアクセス許可をすれば良いのかも気になるかと思います。

試しにAmazon FSx for NetApp ONTAP(FSxN)をセルフマネージドADに参加させ、セルフマネージドADと信頼関係にあるAWS Managed Microsoft ADのユーザーを使ってFSxNにSMBで接続をします。

いきなりまとめ

  • セルフマネージドActive Directoryと信頼関係にあるAWS Managed Microsoft ADのユーザーを使ってFSxNにSMBで接続することは可能
  • FSxNのSMBサーバーが属しているドメインと異なるドメインのユーザーからのアクセスを許可したい場合は、SMBサーバーのドメインからアクセス許可したいドメインユーザーのドメインへの片方向の信頼関係を作成する
    • マルチプロトコルアクセスの場合は双方向の信頼関係を組む必要がある
  • ドメインユーザーをグローバルセキュリティグループやドメインローカルグループに所属させた場合、一度サインアウトされるまで所属しているグループに対するアクセス権限はドメインユーザーに反映されない

やってみた

検証環境

検証環境は以下のとおりです。

セルフマネージドActive Directoryと信頼関係にあるAWS Managed Microsoft ADのユーザーを使ってAmazon FSx for NetApp ONTAPにSMBで接続してみた

今回はcorp.non-97.netnon-97.privateという2つのシングルフォレスト・シングルドメインの間で信頼関係(フォレストの信頼)を行います。なお、外部の信頼でも問題ないようです。

企業ドメインは信頼されたドメインのロールを担い、AWS Directory Service マネージドドメインは信頼するドメインのロールを担います。検証済み認証リクエストは、ドメイン間を一方向にしか移動しません。これにより、企業ドメインのアカウントがマネージドドメインで共有されているリソースに対して認証を行うことができます。この場合、Amazon FSx はマネージドドメインとのみ対話します。マネージドドメインは、認証リクエストを企業ドメインに渡します。

注記
信頼されたドメインに対して Amazon FSx で外部の信頼タイプを使用することもできます。

チュートリアル 1:スタートするための前提条件 - Amazon FSx for Windows File Server

今回はセルフマネージドADからManaged MSADへの一方向の信頼関係を組みます。マルチプロトコルアクセスを実現するためにUNIXユーザーをドメインユーザーにマッピングする際は双方向で信頼関係を組む必要があるようです。

原因

  • ONTAPは最初にUNIXユーザを認証し、次にS4U2Selfを使用してWindowsクレデンシャルを構築します(トークングループへのフォールバック)。

  • Kerberos制約委任では、ドメインAのサーバ(サービス)が、ドメインBのユーザの認可情報を要求している場合、双方向の信頼が必要なユーザの代わりにサービスチケットを取得できる必要があります。

  • RFE 1052237-NFSマウントが混在/ NTFSセキュリティ形式のボリューム/ qtreeを使用していて、環境に一方向の信頼がある場合に中断される

解決策

  • この問題を解決するには、双方向の信頼が必要です。
  • 双方向の信頼によるエクスポージャーを制限するには、 選択認証を 使用して、CIFSサーバコンピュータオブジェクトなどの特定のオブジェクトのみが信頼を通過できないようにします。
    • ファイル所有権の設定ワークフローの一環として 、ONTAPはユーザ(所有者として設定)のWindowsグループメンバーシップを取得して ユーザクレデンシャルを作成します。
    • これにより、SVMは S4U2selfを使用してユーザのクレデンシャルを取得できます。これは 匿名のSAMRパイプを使用した場合に比べて正確であるだけでなく、より安全な 方法でもあります。

ONTAP は、一方向の信頼を介して、信頼できるドメインからWindowsユーザにUNIXユーザをマッピングすることができません - NetApp

シングルフォレスト・シングルドメインの場合はAGDLP、マルチフォレストの場合はAGUDLPが推奨とされているようです。

アルファベットのそれぞれの意味は以下のとおりです。

  • A : Account (アカウント)
  • G : Global Group (グローバルグループ)
  • DL : Domain Local Group (ドメインローカルグループ)
  • U : Universal Group (ユニバーサルグループ)
  • P : Permission (権限)

急にユニバーサルグループやグローバルグループ、ドメインローカルグループと出てきましたが、こちらフォレストやドメインのリソースのグルーピングをする際に使用します。詳細は以下Microsoft公式ドキュメントをご覧ください。

https://learn.microsoft.com/ja-jp/windows-server/identity/ad-ds/manage/understand-security-groups#bkmk-domainadmins

ざっくりとした使い分けは以下で良いと思います。

  • ユニバーサルグループ: フォレスト内の複数のドメイン内のユーザーをグルーピングする場合
  • グローバルグループ: 単一ドメイン内のユーザーをグルーピングする場合
  • ドメインローカルグループ: 特定のコンピューターやオブジェクトの権限設定をする場合

今回はシングルフォレスト・シングルドメインなのでAGDLPで行います。ユニバーサルグループを使ってフォレスト内の複数ドメインユーザーをまとめる必要はないためです。

AGDLPのイメージは以下のとおりです。

AGDLPのイメージ

AGDLPを言葉で説明すると以下のとおりです。

  • アカウント(A)を
  • ドメイン内でグローバルグループ(G)を使ってまとめ
  • グローバルグループをドメインローカルグループ(DL)に所属させ
  • ファイル共有にて、ドメインローカルに対して権限を付与する(P)

つまりは、ドメインローカルグループを権限付与の単位で分け、グローバルセキュリティグループをユーザー管理単位を分離することになります。これにより、「この権限が割り振られているユーザーは、このグループに属している」や「これらの役職のユーザーには、まとめてこの権限を割り当てるべき」などが分かりやすくなり、ファイルサーバーへのアクセス権限の管理がしやすくなります。

一方、グローバルグループ個別に権限を割り当てるAGPはファイル共有数が増加する場合、ドメインローカルグループに直接ユーザーを所属させるADLPはユーザー数が増加する場合に権限を見直す回数が増加するため、管理がスケールしづらいです。これらで管理する場合は小規模環境で使用するようにしましょう。

corp.non-97.netのAD DCの作成

実際に試してみましょう。

corp.non-97.netのAD DCの作成は以下記事の検証で使用したものを流用します。

https://dev.classmethod.jp/articles/amazon-fsx-for-netapp-ontap-delegated-file-system-administrators-group/

また、ドメインユーザーtest-user01test-user02を用意し、どちらもFSxAdminGroupというグローバルセキュリティグループに属させています。こちらも以下記事で用意したものを流用します。詳細はやってみた-ドメインユーザーの準備の章をご覧ください。

https://dev.classmethod.jp/articles/amazon-fsx-for-netapp-ontap-access-based-enumeration/#toc-5

corp.non-97.netドメインに参加しているSMBサーバーの確認

FSxNファイルシステムはマネジメントコンソールから作成しました。

FSxNファイルシステムおよび、SVM(正しくはSMBサーバー)がドメイン参加するために必要なサービスアカウント作成方法は以下記事のやってみた-サービスアカウントの作成やってみた-Amazon FSx for NetApp ONTAPのファイルシステムの作成を参考にしてください。

https://dev.classmethod.jp/articles/amazon-fsx-netapp-ontap-single-availability-zone-deployment/#toc-6

FSxNに接続して、corp.non-97.netドメインに参加しているSMBサーバーSVM.corp.non-97.netの状態を確認します。

> ssh <fsxadmin@management.fs-01f10c043502538c8.fsx.us-east-1.amazonaws.com>
The authenticity of host 'management.fs-01f10c043502538c8.fsx.us-east-1.amazonaws.com (10.0.8.27)' can't be established.
ECDSA key fingerprint is SHA256:P3tf0rtdzgJUWApBIgWZvDmI96cvvd+P/+SkCyXugz0.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'management.fs-01f10c043502538c8.fsx.us-east-1.amazonaws.com,10.0.8.27' (ECDSA) to the list of known hosts.
Password:

This is your first recorded login.
Your privilege has changed since last login.

# SMBサーバーの確認

::> cifs show
            Server          Status    Domain/Workgroup Authentication
Vserver     Name            Admin     Name             Style
----------- --------------- --------- ---------------- --------------
svm         SVM             up        CORP             domain

::> cifs show -instance

                                          Vserver: svm
                         CIFS Server NetBIOS Name: SVM
                    NetBIOS Domain/Workgroup Name: CORP
                      Fully Qualified Domain Name: CORP.NON-97.NET
                              Organizational Unit: OU=FSxForONTAP,DC=corp,DC=non-97,DC=net
Default Site Used by LIFs Without Site Membership:
                                   Workgroup Name: -
                             Authentication Style: domain
                CIFS Server Administrative Status: up
                          CIFS Server Description:
                          List of NetBIOS Aliases: -

# ファイル共有の確認

::> cifs share show
Vserver        Share         Path              Properties Comment  ACL
-------------- ------------- ----------------- ---------- -------- -----------
svm            c$            /                 oplocks    -        BUILTIN\Administrators / Full Control
                                               browsable
                                               changenotify
                                               show-previous-versions
svm            ipc$          /                 browsable  -        -
2 entries were displayed.

正常にドメイン参加していそうですね。

non-97.privateのManaged Microsoft ADの用意

non-97.privateのManaged Microsoft ADのマネジメントコンソールから作成します。

ディレクトリタイプではAWS Managed Microsoft ADを選択します。

1.ディレクトリタイプを選択

今回は検証用途なのでStandard Editionを選択します。組織規模によってはEnterprise Editionを選択してください。なお、2024/6/18時点では作成後にEditionを変更することはできないのでご注意ください。

2.ディレクトリ情報を入力

VPCやサブネットを選択します。

3.VPC とサブネットを選択

内容を確認してディレクトリの作成をクリックします。

4.確認と作成

30分ほど待つと、ステータスがアクティブになっていました。

Managed Microsoft ADにアタッチされているセキュリティグループは以下のとおりです。インバウンドルールで0.0.0.0/0で許可されているものが多いため、実際に運用する際は適切なレンジを指定することを推奨します。

  • Managed MSADのセキュリティグループのインバウンドルール
    6.Managed MSADのセキュリティグループの確認

  • Managed MSADのセキュリティグループのアウトバウンドルール
    6.Managed MSADのセキュリティグループの確認2

non-97.private操作用EC2インスタンスの用意

non-97.private操作用EC2インスタンスの用意をします。

今回はAMIにWindows_Server-2022-Japanese-Full-Base-2024.05.15を使用しました。

起動完了後、Managed Microsoft ADを管理するEC2インスタンスに必要な機能をインストールします。


# 必要な機能のインストール
>
> $result = Install-WindowsFeature -Name RSAT-ADDS,RSAT-DNS-Server,GPMC

# インストールされている機能の確認
>
> $result.FeatureResult | Format-Table -AutoSize

Display Name                                      Name                Success # Msg Restart Needed Skip Reason
------------                                      ----                ------- ----- -------------- -----------
グループ ポリシーの管理                           GPMC                True    0     False          NotSkipped
リモート サーバー管理ツール                       RSAT                True    0     False          NotSkipped
Active Directory 管理センター                     RSAT-AD-AdminCenter True    0     False          NotSkipped
Windows PowerShell の Active Directory モジュール RSAT-AD-PowerShell  True    0     False          NotSkipped
AD DS および AD LDS ツール                        RSAT-AD-Tools       True    0     False          NotSkipped
AD DS ツール                                      RSAT-ADDS           True    0     False          NotSkipped
AD DS スナップインおよびコマンドライン ツール     RSAT-ADDS-Tools     True    0     False          NotSkipped
DNS サーバー ツール                               RSAT-DNS-Server     True    0     False          NotSkipped
役割管理ツール                                    RSAT-Role-Tools     True    0     False          NotSkipped

インストール後、Managed Microsoft ADのドメイン(non-97.private)に参加します。参加する際に事前にDNSサーバーをManaged Microsoft ADを向けさせます。


# NIC情報からDNS Clientオブジェクト取得
>
> $client = Get-NetAdapter | Get-DnsClient

# 変更前設定確認
>
> $client | Get-DnsClientServerAddress -AddressFamily IPv4

InterfaceAlias               Interface Address ServerAddresses
                             Index     Family
--------------               --------- ------- ---------------
イーサネット 3                       8 IPv4    {10.0.0.2}

# 設定変更
>
> $dnsServers = @("10.0.8.44", "10.0.9.185") # Managed Microsoft ADのIPアドレス
> $client | Set-DnsClientServerAddress -ServerAddresses $dnsServers
> $client | Get-DnsClientServerAddress -AddressFamily IPv4

InterfaceAlias               Interface Address ServerAddresses
                             Index     Family
--------------               --------- ------- ---------------
イーサネット 3                       8 IPv4    {10.0.8.44, 10.0.9.185}

# ドメイン参加
>
> $password=ConvertTo-SecureString -AsPlainText -Force "<Managed Microsoft ADのAdminのパスワード>"
> $credential=New-Object System.Management.Automation.PSCredential("non-97.private\Admin",$password)
> Add-Computer -DomainName non-97.private -Credential $credential -Restart -Force

OS再起動後、non-97.private\AdminでRDP接続します。接続後、non-97.privateのAdminでログインしていることを確認します。

> whoami -fqdn
CN=Admin,OU=Users,OU=non-97,DC=non-97,DC=private

信頼関係の作成

以下ドキュメントを参考に、non-97.privateからcorp.non-97.net上のリソースにアクセスできるように、corp.non-97.netからnon-97.privateへ片方向の信頼関係を作成します。

https://docs.aws.amazon.com/ja_jp/directoryservice/latest/admin-guide/ms_ad_connect_existing_infrastructure.html

事前準備として、corp.non-97.netのAD DCのセキュリティグループで、non-97.privateのManaged Microsoft ADからの全ての通信を許可します。

8.セルフマネージドADのセキュリティグループ修正

corp.non-97.netがnon-97.privateの名前解決ができるように、corp.non-97.netにてnon-97.privateへの条件付きフォワーダーを設定します。


# 現在のDNSサーバー設定の確認
>
> Get-DnsServerZone                                                                                                                                                                                                    ZoneName                            ZoneType        IsAutoCreated   IsDsIntegrated  IsReverseLookupZone  IsSigned
--------                            --------        -------------   --------------  -------------------  --------
_msdcs.corp.non-97.net              Primary         False           True            False                False
0.in-addr.arpa                      Primary         True            False           True                 False
127.in-addr.arpa                    Primary         True            False           True                 False
255.in-addr.arpa                    Primary         True            False           True                 False
corp.non-97.net                     Primary         False           True            False                False
TrustAnchors                        Primary         False           True            False                False

# 条件付きフォワーダーの設定
>
> $fqdn = 'non-97.private'
> $dnsServers = @('10.0.8.44','10.0.9.185') # Managed Microsoft ADのDNS IPアドレス
> $params = @{
    Name = $fqdn
    MasterServers = $dnsServers
    ReplicationScope = 'Domain'
}
> Add-DnsServerConditionalForwarderZone @params

# 条件付きフォワーダーが設定されたことを確認
>
> Get-DnsServerZone

ZoneName                            ZoneType        IsAutoCreated   IsDsIntegrated  IsReverseLookupZone  IsSigned
--------                            --------        -------------   --------------  -------------------  --------
_msdcs.corp.non-97.net              Primary         False           True            False                False
0.in-addr.arpa                      Primary         True            False           True                 False
127.in-addr.arpa                    Primary         True            False           True                 False
255.in-addr.arpa                    Primary         True            False           True                 False
corp.non-97.net                     Primary         False           True            False                False
non-97.private                      Forwarder       False           True            False
TrustAnchors                        Primary         False           True            False                False

corp.non-97.netからnon-97.privateへ片方向の信頼関係を作成します。

まずはcorp.non-97.net側からです。


# 現在の信頼関係一覧
>
> Get-ADTrust -Filter *

# 信頼関係の作成
>
> $targetForestName = 'non-97.private'
> $trustPassword = '<信頼パスワード (後でManaged Microsoft AD設定時に使う)>'
> $trustDirection = 'Outbound'
> $forest = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()
> $forest.CreateLocalSideOfTrustRelationship($targetForestName, $trustDirection, $trustPassword)

# 信頼関係が作成されたことを確認
>
> Get-ADTrust -Filter *

Direction               : Outbound
DisallowTransivity      : False
DistinguishedName       : CN=non-97.private,CN=System,DC=corp,DC=non-97,DC=net
ForestTransitive        : True
IntraForest             : False
IsTreeParent            : False
IsTreeRoot              : False
Name                    : non-97.private
ObjectClass             : trustedDomain
ObjectGUID              : 420b253d-a88d-4de4-b0b6-5d22e12e4cb3
SelectiveAuthentication : False
SIDFilteringForestAware : False
SIDFilteringQuarantined : False
Source                  : DC=corp,DC=non-97,DC=net
Target                  : non-97.private
TGTDelegation           : False
TrustAttributes         : 8
TrustedPolicy           :
TrustingPolicy          :
TrustType               : Uplevel
UplevelOnly             : False
UsesAESKeys             : False
UsesRC4Encryption       : False

Managed Microsoft AD側でも信頼関係の作成を行います。

フォレストの信頼で、corp.non-97.netに対して入力方向で信頼するように信頼関係を作成します。10.0.0.139はcorp.non-97.netのAD DC用EC2インスタンスのIPアドレスです。

9. 信頼関係の追加

数分待ち、信頼関係の作成が完了したことを確認します。

10.信頼関係が設定されたことを確認

信頼関係を作成すると同時にcorp.non-97.netに対する条件付きフォワーダーが設定されているため、non-97.privateのAdminユーザーでSVM.corp.non-97.netの名前解決ができることを確認します。

> nslookup SVM.corp.non-97.net
サーバー:  ip-c61301d0.non-97.private
Address:  10.0.8.44

権限のない回答:
名前:    SVM.corp.non-97.net
Address:  10.0.8.153

問題なく名前解決できました。

non-97.privateにRDP接続用ユーザーの追加

以下記事を参考にnon-97.privateにRDP接続用ユーザーを追加します。

https://dev.classmethod.jp/articles/rdp-connection-from-aws-systems-manager-fleet-manager-as-a-domain-user/#toc-9

作成するユーザーはtest-user-1test-user-2です。


# ユーザーの作成
>
> New-ADUser `
  -Name "test-user-1" `
  -UserPrincipalName "<[email protected]>" `
  -Accountpassword (Read-Host -AsSecureString "AccountPassword") `
  -Path "OU=Users,OU=non-97,DC=non-97,DC=private" `
  -PasswordNeverExpires $True `
  -Enabled $True
AccountPassword: ***********

> New-ADUser `
  -Name "test-user-2" `
  -UserPrincipalName "<[email protected]>" `
  -Accountpassword (Read-Host -AsSecureString "AccountPassword") `
  -Path "OU=Users,OU=non-97,DC=non-97,DC=private" `
  -PasswordNeverExpires $True `
  -Enabled $True
AccountPassword: **********************

# ユーザーが作成されたことを確認
>
> Get-ADUser -Filter "*" -SearchBase "OU=Users,OU=non-97,DC=non-97,DC=private"

DistinguishedName : CN=CORP$,OU=Users,OU=non-97,DC=non-97,DC=private
Enabled           : True
GivenName         :
Name              : CORP$
ObjectClass       : user
ObjectGUID        : 5944a11f-fe73-4e1c-bbcb-48c14b6071ad
SamAccountName    : CORP$
SID               : S-1-5-21-1859619966-4240876272-1758126325-1146
Surname           :
UserPrincipalName :

DistinguishedName : CN=test-user-1,OU=Users,OU=non-97,DC=non-97,DC=private
Enabled           : True
GivenName         :
Name              : test-user-1
ObjectClass       : user
ObjectGUID        : 29ec8a3a-6fe5-41b7-961b-e3ca5732d31a
SamAccountName    : test-user-1
SID               : S-1-5-21-1859619966-4240876272-1758126325-1609
Surname           :
UserPrincipalName : <test-user-1@non-97.private>

DistinguishedName : CN=test-user-2,OU=Users,OU=non-97,DC=non-97,DC=private
Enabled           : True
GivenName         :
Name              : test-user-2
ObjectClass       : user
ObjectGUID        : f981c655-784a-40b6-9ddd-3abb4055ee79
SamAccountName    : test-user-2
SID               : S-1-5-21-1859619966-4240876272-1758126325-1610
Surname           :
UserPrincipalName : <test-user-2@non-97.private>

DistinguishedName : CN=Admin,OU=Users,OU=non-97,DC=non-97,DC=private
Enabled           : True
GivenName         :
Name              : Admin
ObjectClass       : user
ObjectGUID        : 298727de-a19b-4bad-9b94-6598a93dfaa2
SamAccountName    : Admin
SID               : S-1-5-21-1859619966-4240876272-1758126325-1112
Surname           :
UserPrincipalName : <admin@non-97.private>

rdp-groupというグローバルセキュリティグループを作成し、作成したユーザーを追加します。

11.RDP用のセキュリティグループに所属させる

non-97.privateのComputers OU内のコンピュータ内にRDP接続できるようにGPOを作成します。名前はrdp-gpoとしました。

12.rdp-gpoの作成

rdp-groupに属するユーザーにRemote Desktop Users (ビルトイン)を適用します。

GPOを強制的に反映させます。

> gpupdate /force
ポリシーを最新の情報に更新しています...

コンピューター ポリシーの更新が正常に完了しました。
ユーザー ポリシーの更新が正常に完了しました。

non-97.privateのtest-user-1でRDP接続できることを確認します。

14.test-user-1でRDPできることを確認

> whoami -fqdn
CN=test-user-1,OU=Users,OU=non-97,DC=non-97,DC=private

RDP接続できました。

ファイル共有の作成

SMBサーバー上でshare1というファイル共有を作成します。

::> cifs share create -vserver svm -share-name share1 -path /vol1

::> cifs share show
Vserver        Share         Path              Properties Comment  ACL
-------------- ------------- ----------------- ---------- -------- -----------
svm            c$            /                 oplocks    -        BUILTIN\Administrators / Full Control
                                               browsable
                                               changenotify
                                               show-previous-versions
svm            ipc$          /                 browsable  -        -
svm            share1        /vol1             oplocks    -        Everyone / Full Control
                                               browsable
                                               changenotify
                                               show-previous-versions
3 entries were displayed.

ファイル共有でEveryone Full Controlで許可している場合に、non-97.privateのユーザーが操作できることを確認

share1というファイル共有のACL(共有アクセス権)はEveryoneのFull Controlで許可です。

この状態でnon-97.privateのユーザーtest-user-1がファイル共有内で読み書きできるかを確認します。


# share1をマウント
>
> New-PSDrive -Name "Z" -PSProvider FileSystem -Root "\\SVM.corp.non-97.net\share1"

Name           Used (GB)     Free (GB) Provider      Root                                               CurrentLocation
----           ---------     --------- --------      ----                                               ---------------
Z                                      FileSystem    \\SVM.corp.non-97.net\share1

# share1上に書き込みできることを確認
>
> echo test.txt > Z:\test.txt

# 書き込みできたたことを確認
>
> ls Z:\

    ディレクトリ: \\SVM.corp.non-97.net\share1

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----        2024/06/14      8:40             22 test.txt

> cat Z:\test.txt
test.txt

問題なく読み書きできました。

cifs session showで現在のセッション一覧を確認します。

::> cifs session show

Node:    FsxId01f10c043502538c8-01
Vserver: svm
Connection Session                                        Open         Idle      Connection
ID         ID      Workstation      Windows User         Files         Time           Count
---------- ------- ---------------- ---------------- --------- ------------ ---------------
2968530356 3286220353096908806                                       1m 47s               4
                   10.0.0.223       NON-97\test-             3
                                    user-1

::> cifs session show -instance

Vserver: svm

                            Node: FsxId01f10c043502538c8-01
                      Session ID: 3286220353096908806
                   Connection ID: 2968530356
    Incoming Data LIF IP Address: 10.0.8.153
          Workstation IP Address: 10.0.0.223
        Authentication Mechanism: NTLMv2
           User Authenticated as: domain-user
                    Windows User: NON-97\test-user-1
                       UNIX User: pcuser
                     Open Shares: 1
                      Open Files: 3
                      Open Other: 0
                  Connected Time: 3m 0s
                       Idle Time: 1m 52s
                Protocol Version: SMB3_1
          Continuously Available: No
               Is Session Signed: false
                    NetBIOS Name: -
           SMB Encryption Status: unencrypted
               Large MTU Enabled: true
                Connection Count: 4
                   Active Shares: share1

現在接続しているnon-97.privateのtest-user-1のセッションを確認できました。

ドメインローカルグループの作成

それではcorp.non-97.net内にドメインローカルグループを作成し、AGDLPの形で権限を付与する準備をします。

domain-localというドメインローカルグループを作成しました。

15.ドメインローカルグループの作成

作成したドメインローカルグループにcorp.non-97.netのFSxAdminGroupとnon-97.privateのrdp-groupを所属させます。

18.domain-localのメンバー

FSxAdminGroupのメンバーは以下のとおりです。

16.FSxAdminGroupのメンバー

なお、corp.non-97.net上からnon-97.private上のリソースを参照する際に認証が求めらたら都度入力をしてあげます。

17.必要に応じて入力

ドメインローカルグループに付与した権限で動作することを確認

ドメインローカルグループに付与した権限で動作することを確認します。

corp.non-97.netのdomain-localにReadを許可します。


# Everyone Full Controlの許可を削除

::*> cifs share access-control delete -share share1 -user-or-group Everyone

# corp.non-97.netのdomain-localにReadを許可

::*> cifs share access-control create -share share1 -user-or-group CORP\domain-local -user-group-type windows -permission Read

# 共有アクセス権限の確認

::*> cifs share access-control show -share share1
               Share       User/Group                  User/Group  Access
Vserver        Name        Name                        Type        Permission
-------------- ----------- --------------------------- ----------- -----------
svm            share1      CORP\domain-local           windows     Read

この状態のイメージは以下のとおりです。(FSxAdminは割愛)

権限割り当てのイメージ

この状態でnon-97.privateのtest-user-1から読み込みできるか確認します。

> ls Z:
ls : アクセスが拒否されました。
発生場所 行:1 文字:1
- ls Z:
- ~~~~~
    + CategoryInfo          : PermissionDenied: (Z:\:String) [Get-ChildItem], UnauthorizedAccessException
    + FullyQualifiedErrorId : ItemExistsUnauthorizedAccessError,Microsoft.PowerShell.Commands.GetChildItemCommand

ls : パス 'Z:\' が存在しないため検出できません。
発生場所 行:1 文字:1
- ls Z:
- ~~~~~
    + CategoryInfo          : ObjectNotFound: (Z:\:String) [Get-ChildItem], ItemNotFoundException
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

はい、拒否されました。

これはグループの変更は既存のセッションに影響を与えないためです。

ユーザーがリソース セッションを開始した後にユーザーのグループ メンバーシップが変更された場合、変更がユーザーのリソース アクセスに実際に影響を与えるタイミングは、次の要因によって制御されます。

  • グループ メンバーシップの変更は、既存のセッションには影響しません。
    既存のセッションは、ユーザーがサインアウトするか、それ以外の場合はセッションを終了するか、セッションの有効期限が切れるまで続行されます。 セッションの有効期限が切れると、次のいずれかが発生します。
    • クライアントはセッション チケットを再送信するか、新しいセッション チケットを送信します。 この操作により、セッションが更新されます。
    • クライアントはもう一度接続しようとしません。 セッションは更新されません。
  • グループ メンバーシップの変更は、現在の TGT や、その TGT を使用して作成されたセッション チケットには影響しません。
    チケット付与サービス (TGS) は、TGT からのグループ情報を使用して、Active Directory 自体にクエリを実行する代わりにセッション チケットを作成します。 TGT は、ユーザーがクライアントをロックするかサインアウトするか、TGT の有効期限が切れる (通常は 10 時間) まで更新されません。 TGT は 10 日間更新できます。

一部の VPN 接続でグループ メンバーシップの変更が更新されない - Windows Client | Microsoft Learn

今回はtest-user-1にRDP接続してから、test-user-1が所属しているグローバルセキュリティグループrdp-groupを、ドメインローカルグループのdomain-localに所属させています。そのため、domain-localに対するアクセス権限を付与したとしても、既存のRDP接続のセッションには反映されません。

一度test-user-1のRDP接続からサインアウトして、再接続します。

再接続後同様の操作をしたところ、問題なく操作できました。

> whoami -fqdn
CN=test-user-1,OU=Users,OU=non-97,DC=non-97,DC=private

> ls Z:\

    ディレクトリ: Z:\

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----        2024/06/14     10:11             22 test.txt

> cat Z:\test.txt
test.txt

> echo test2.txt > Z:\test2.txt
out-file : パス 'Z:\test2.txt' へのアクセスが拒否されました。
発生場所 行:1 文字:1
- echo test2.txt > Z:\test2.txt
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (:) [Out-File], UnauthorizedAccessException
    + FullyQualifiedErrorId : FileOpenFailure,Microsoft.PowerShell.Commands.OutFileCommand

意図したとおり、書き込みは拒否されていますね。

Full Controlを付与して書き込みできることを確認します。

::> cifs share access-control modify -share share1 -user-or-group CORP\domain-local -permission Full_Control

::> cifs share access-control show -share share1
               Share       User/Group                  User/Group  Access
Vserver        Name        Name                        Type        Permission
-------------- ----------- --------------------------- ----------- -----------
svm            share1      CORP\domain-local           windows     Full_Control
> echo test2.txt > Z:\test2.txt

> cat Z:\test2.txt
test2.txt

> ls Z:\

    ディレクトリ: Z:\

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----        2024/06/14     10:11             22 test.txt
-a----        2024/06/18      0:25             24 test2.txt

問題なく書き込みできました。

corp.non-97.netのtest-user01からも試してみます。

> whoami -fqdn
CN=test-user01,OU=FSxForONTAP,DC=corp,DC=non-97,DC=net

> New-PSDrive -Name "Z" -PSProvider FileSystem -Persist -Root "\\SVM.corp.non-97.net\share1"

Name           Used (GB)     Free (GB) Provider      Root                                               CurrentLocation
----           ---------     --------- --------      ----                                               ---------------
Z                   0.00         60.80 FileSystem    \\SVM.corp.non-97.net\share1

> ls Z:\

    Directory: Z:\

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         6/14/2024  10:11 AM             22 test.txt
-a----         6/18/2024  12:25 AM             24 test2.txt

> echo test3.txt > Z:\test3.txt
> ls Z:\

    Directory: Z:\

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         6/14/2024  10:11 AM             22 test.txt
-a----         6/18/2024  12:25 AM             24 test2.txt
-a----         6/18/2024  12:41 AM             24 test3.txt

> cat Z:\test3.txt
test3.txt

こちらでも問題なく読み書きできました。

セッション一覧を確認します。

::> cifs session show

Node:    FsxId01f10c043502538c8-01
Vserver: svm
Connection Session                                        Open         Idle      Connection
ID         ID      Workstation      Windows User         Files         Time           Count
---------- ------- ---------------- ---------------- --------- ------------ ---------------
2968530356 3286220353096908826                                      14m 20s               4
                   10.0.0.223       NON-97\test-             3
                                    user-1
2968530389 3286220353096908829                                      14m 11s               4
                   10.0.0.139       CORP\test-user01         1
2 entries were displayed.

::> cifs session show -instance

Vserver: svm

                            Node: FsxId01f10c043502538c8-01
                      Session ID: 3286220353096908826
                   Connection ID: 2968530356
    Incoming Data LIF IP Address: 10.0.8.153
          Workstation IP Address: 10.0.0.223
        Authentication Mechanism: NTLMv2
           User Authenticated as: domain-user
                    Windows User: NON-97\test-user-1
                       UNIX User: pcuser
                     Open Shares: 1
                      Open Files: 3
                      Open Other: 0
                  Connected Time: 14h 36m 42s
                       Idle Time: 14m 48s
                Protocol Version: SMB3_1
          Continuously Available: No
               Is Session Signed: false
                    NetBIOS Name: -
           SMB Encryption Status: unencrypted
               Large MTU Enabled: true
                Connection Count: 4
                   Active Shares: share1

                            Node: FsxId01f10c043502538c8-01
                      Session ID: 3286220353096908829
                   Connection ID: 2968530389
    Incoming Data LIF IP Address: 10.0.8.153
          Workstation IP Address: 10.0.0.139
        Authentication Mechanism: Kerberos
           User Authenticated as: domain-user
                    Windows User: CORP\test-user01
                       UNIX User: pcuser
                     Open Shares: 1
                      Open Files: 1
                      Open Other: 0
                  Connected Time: 3h 56m 45s
                       Idle Time: 14m 39s
                Protocol Version: SMB3_1
          Continuously Available: No
               Is Session Signed: false
                    NetBIOS Name: -
           SMB Encryption Status: unencrypted
               Large MTU Enabled: true
                Connection Count: 4
                   Active Shares: share1

2 entries were displayed.

それぞれのセッションを確認できました。

test-user-1で、ファイル共有上のファイルをメモ帳で開き、cifs session file showで開いているファイル一覧に表示されるのかも確認しましょう。

::> vserver cifs session file show
This table is currently empty.

表示されませんね。

NetAppのKBを確認したところ、メモ帳はフォーカスが外れたタイミングでファイルを閉じてしまうようです。

によって報告されるオープンファイルの数は、アプリケーションによってvserver cifs session file show現在使用されている数です。アプリケーションの動作によっては、混乱を招く可能性があります。

たとえば、フォーカスが別のアプリケーションに移動されたときにメモ帳がファイルを閉じるのに対して、 Internet Explorer は使用されていない期間が経過するとファイルを閉じます。

vserver cifs session file showコマンドを実行して開いているファイルの数を確認しようとしている場合、ファイルロックはこの合計にカウントされます。 vserver locks show 代わりに使用できます。

「 vserver cifs session file show 」で開いているファイルが一部表示されないのはなぜですか? - NetApp

メモ帳にでファイルを開いた瞬間にcifs session file showを叩いてみます。

::> cifs session file show

Node:       FsxId01f10c043502538c8-01
Vserver:    svm
Connection: 2968530356
Session:    3286220353096908826
Connection Count: 4
File    File      Open Hosting                               Continuously
ID      Type      Mode Volume          Share                 Available
------- --------- ---- --------------- --------------------- ------------
42      Regular   r    vol1            share1                No
Path: test.txt

::> cifs session file show -instance

                  Node: FsxId01f10c043502538c8-01
               Vserver: svm
               File ID: 49
         Connection ID: 2968530356
            Session ID: 3286220353096908826
      Connection Count: 4
             File Type: Regular
             Open Mode: r
Aggregate Hosting File: aggr1
   Volume Hosting File: vol1
            CIFS Share: share1
  Path from CIFS Share: test.txt
            Share Mode: rw
           Range Locks: 0
Continuously Available: No
           Reconnected: No
        FlexGroup MSID: 0

開いているファイルの情報を確認できました。

信頼関係を組んで適切な権限を付与しよう

セルフマネージドActive Directoryと信頼関係にあるAWS Managed Microsoft ADのユーザーを使ってAmazon FSx for NetApp ONTAPにSMBで接続してみました。

最低限片方向の信頼関係があれば問題なく接続できるようです。

アクセス権限の設定は組織規模や既存のグループ設計によって適切なものは異なると感じています。最初はAGPでスタートし、徐々にAGLDPに寄せていくという形も良いかなと思います。

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.